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This thesis places the Information Resource Management 
Architecture of the U. S. Coast Guard in the 'contagious 
growth' stage of Nolan's model of organizational computer 
growth. Control is the next stage predicted by the model. 
The financial accounting basis of EDP chargeback and control 
systems is examined as a precursor to developing five 
management control requirements of the IRM architecture. 
These include (1) aggregate financial accounting for infor- 
mation services, (2) an auditable user access/authorization 
scheme, (3) a user-oriented chargeback system, (4) pricing 
to establish an information marketplace, and (5) an informa- 
tion decision tool to assist in user tradeoff decisions 
between information services. Finally, an integrated system 
to satisfy these requirements at the Coast Guard District 
Office level of the IRM architecture is described, based on 
a Local Area Network system. 
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I. THE COAST GUARD IRM ARCHITECTURE 



A. INFORMATION SYSTEM PROJECTS 

In the early 1 970's, the U.S. Coast Guard began automa- 
ting and integrating the administrative and communications 
systems which constitute its servicewide Information System. 
A number of major Information System Projects were 
identified, each specifying a single functional system, 
usually vertically integrated from the data-entry field unit 
through to the Program Manager level at Coast Guard 
Headquarters. Examples include the Operational Information 
System project (OPINS), the Personnel Management Information 
System (PMIS), the Marine Safety Information System (MSIS) , 
and the Standardized Aids to Navigation System (SANDS). 
Other projects became necessary to support these Information 
Systems; the Standard Terminal Project competitively bid a 
requirements contract for procurement of up to 3900 
intelligent communications and data entry terminals, and the 
Semi -Automated Message Processing Project (SAMPS) began 
computerizing manpower intensive relay points in the record 
communications network. 

B. THE OFFICE OF T 

The Paperwork Reduction Act of 1980 mandated a central 
point of information management in each agency. In 1981 , 
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responsibility for the various Information Projects, and 
for Information Resource Management Coast Guard-wide was 
vested in a newly formed Office of Command, Control and 
Communications (C^), synthesized from the former Financial 
Information Systems, Electronic/Electrical Engineering, and 
Telecommunications Management Divisions at Coast Guard 
Headquarters. Its staff symbol, ( Comma ndan t ) G-T , became 
widespread verbal shorthand and the "Office of T" was born. 

C. THE U.S. COAST GUARD INFORMATION RESOURCE MANAGEMENT 

ARCHITECTURE 

An overall schema was needed, to guide the integration 
and coordination of the various separate information systems 
and the supporting projects into a servicewide Coast Guard 
Information System. The Office of T developed and published 
the Coast Guard Information Resource Management Architecture 
illustrated in Figure 1. The two primary policy documents 
supporting and implementing this architecture are the 
(DRAFT) Command, Control and Communications (C^) Plan [Ref. 
1], and the Command, Control and Communications (C^) Support 
Program Plan, 1982-1992, [Ref. 2]. 

1 . Overview and Critical Success Factors 

The best overview and explanation of the Information 
Resource Management (IRM) Architecture is in the C^ Plan 
itself : 
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U.S. Coast Guard Information 
Resources Management Architecture 



TIME SHARING SVCS 





MAJOt 1 * 0*1 FAQUTY 


Minicomputer 




Rroe«u 


e>° 




DBMS 




AANS 

aUDCCT (A*lt) 

HUMAN USOUtCIS 
AmXIATJOHS 
SOFTWA M PACKAGES 
WffOtT (UUS/SMSP) 

•OATS 



Figure 1. U.S. Coast Guard Information Resources 
Management Architecture 
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"Information Architecture Plan. 

The first step in effective Information Resource 
Management is to develop the Information Architecture 
Plan. This is similar to a business plan in a commercial 
firm. The information needs and activities of the various 
parts of the organization (emphasis added) are collected 
and analyzed to determine the manner in which data must be 
organized to support them. This leads to development of a 
logical model which describes the arrangement and activi- 
ties of the organization. This logical model has been 
found to be quite stable unless the fundamental character 
of the organization is altered or its missions change 
radically in a short time. Because the logical model is 
stable, evolutionary changes can be accommodated.." [Ref. 
1 : p . 3 2 ) . 

The added emphasis underscores the fact that unless 
a part of the organization articulates an information need 
or activity, the Plan cannot address it. Needs of the 
system overall, "global" needs (like a need for management 
control) will not enter the Architecture without a sponsor, 
since they are not the assigned task of any specific 
organizational element. 

The Coast Guard has identified four Critical Success 
Factors for developing the Information Resources Management 
Architecture : 

1 . Intelligent Terminals--to provide a vehicle for local 
processing, source data entry, and access to the net- 
work( s ) , 

2. Data Base Technology--to control the data resource, 

3. The Communications Network--to provide connectivity, 
and 

4. Integration--of the parts into a whole. 

[Ref .3: p. STSP3 ] 



The emphasis on database technology was not intended to 
allow the creation of many parallel vertical information 
systems : 

"The IRM architecture and other policies of the (Office of 
T) program discourages the proliferation of field-unit 
terminals connected independently to single-program 
central data bases. This would be an electronic version of 
our present uncoordinated, overlapping, manual information 
system." [Ref. 1: pp. 4-7] 

The databases shown, at Headquarters, in the District 
Offices, and at major shore facilities, are to be shared, 
multi-purpose databases. 

The number of mini -computer s shown, coupled with the 
identification of intelligent terminals as a Critical 
Success Factor, mean that this is a 'distributed' system. 
Computing power is placed as close as possible to the people 
who need to use it. This contrasts with a centralized system 
where all computing is done at one usually large central 
computer and user terminals are capable only of data entry 
and routine inquiries. 

2 . Classes of Information Serviced 

The C^ Support Plan addresses the three classes of 
information which the IRM Architecture will have to service: 
transactional, hierarchical, and local. Figure 2 illus- 
trates the flow of hierarchical information: 

"This figure shows hierarchical information flowing from 
the smallest unit, to the top of the Coast Guard, and 
ultimately beyond to both Congressional and Executive 
recipients. While all three types of information have 
gray areas of overlap, the essential features of 
hierarchical are aggregation, and use by management over 
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time periods of weeks to years. These two features mean 
that the timeliness of the information is not critical, 
and the precision and detail of the aggregated information 
decreases as the hierarchical level increases . Hierarchi- 
cal information supports the management control and 
strategic control functions of the organization. [Ref. 2: 
p. 4-2 ] 

Hierarchical Information 



Higher Gov't 




Timm: Not Critical 

Data: Complex Structure 

Aggregated £r Summarized 

Use: Manage metre Allocation, Planning, Control 

Traditionally: Paper Systems 

Figure 2. Flow of Hierarchical Information 



Transactional information flow is shown in Figure 3 and 
defined as follows: 

"This figure illustrates transactional information, 
based upon data groupings which flow intact from point-to- 
point in the organization and usually cause or support 
rapid activity. In contrast to hierarchical information 
the precision of transactional information is constant and 
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transactions are not usually aggregated. This information 
type is often found in our present record communications 
and feeds the operational control function( operating the 
organization day-in and day-out). A "message MILSTRIP" is 
a perfect example. Transaction information often has a 
complex input to hierarchical and this input (and often 
its duplication) is a significant problem/cost to the 
Coast Guard." [Ref. 2: p. 4-2] 

(The message MILSTRIP mentioned is a telexed supply 
requisition.) Local information is defined as any and all 
information that an individual or organizational element 
chooses to use and keep when it is not institutionally 
required to do so. 

Transaction Information 




Tim*: Usually Critical 
Data: Simpl* Structure 
Intact End- to- End 
Use: OPS C2 & Dlract Support 
Traditional: CG Record (massage) Communications 



Figure 3. 



Flow of Transactional Information 



3. The Role of the District Office 



Central to all three of the figures depicting 
information flow in the Coast Guard has been the Coast Guard 
District Office. Situated between the strategic level of 
Coast Guard Headquarters and the operational level of the 
field units, the District Headquarters operates at the level 
of management control. Every major Headquarters Office 
and/or Program Manager connects to a corresponding District 
Division or Branch. Districts are responsible for managing 
Coast Guard resources within a given geographic area (i.e. 
Fifth District = Maryland, Virginia, N. Carolina). The 
District Commander (a two-star Admiral) as the principal 
agent and representative of the Commandant, is responsible 
for the administration and general direction of district 
units under his command. Within his District, he is 
responsible for carrying out the functions and duties of the 
Coast Guard and for assuring that these duties are performed 
efficiently, safely and economically. Districts produce the 
majority of transactional information. [Ref. 2: pp. 1-10] 
Table I shows the names and locations of the twelve District 
Offices . 

The District Commander's responsibility for local 
control of Coast Guard resources extends to information 
resources, too. In 1981, three officer billets (One Comman- 
ded 0-5), one Lieutenant (0-3 ) and one Warrant 0fficer(CW0- 
4)) were added to the staffs of each of the twelve District 
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Offices to form the nucleus of an IRM staff. Combined with 
the existing telecommunications organization, they are meant 
to evolve into the provider s / super vi sors of all the 
information services shown in the "CG District" box within 
Figure 1. This District IRM staff will operate the Local 
Area Network and the District Mini -Computer , maintain the 
District database and provide the Information Center 
services specified in the IRM Architecture. 



Table I. U.S. Coast Guard District Office Locations 



District 



First District 
Second District 
Third District 
Fifth District 
Seventh District 
Eighth District 
Ninth District 
Eleventh District 
Twelfth District 
Thirteenth District 
Fourteenth District 
Seventeenth District 



District Headquarters 
Location 

Boston, MA 
St Louis, MO 
New York, NY 
Portsmouth, VA 
Miami, FL 
New Orleans, LA 
Cleveland, OH 
Long Beach, CA 
San Francisco, CA 
Seattle, WA 
Honolulu, HI 
Juneau, AK 



D. THE DISTRICT LOCAL NETWORK 

While the IRM Architecture and its support plans provide 

for and define a local network capability for each District, 

it is not a critical nor a high-priority project. The C^ 

Plan defines the Local Network as follows: 

"Within the district office building and immediate 
surroundings, the local net provides for information 
distribution through interconnected clusters of Standard 
Terminals or other existing office information systems. 
Primary objectives are shared electronic files, electronic 



mail, word processing and shared information processing." 
[Ref. 1 : pp. 1-10] 

The implementing Support Plan notes that the multi-user 
capabilities of the Standard Terminal resemble network 
connectivity, and that clusters of Standard Terminals could 
be interconnected in a 'message mode'. However, this inter- 
connection and more advanced techniques like wideband 
channel local area networks "will not be pursued for general 
Coast Guard use through the mid-80's, although R&D evalua- 
tion would certainly be in order" [Ref. 2: pp. 4-10]. The 
reasons are given in a section titled "Future Technology 
Impact on the Architecture": 

"A number of promising techno logi es .. .have been excluded 
from this version of the support plan. The basic reason 
has been one of practical choice; the limited resources 
available to the program and the need for evolutionary 
growth dictate that higher risk or non-integrable ventures 
be excluded... 



Local Networks 

Mixed voice/data/video has potential payoff, but lack 
of control of most telephone installations makes this 
difficult to exploit. Some use of this later in the 
decade will no doubt occur." [Ref. 2: pp. 4-20]. 

Each District is responsible for the design, acquisition, 

operation and maintenance of information (voice and data) 

networks within the geographic boundaries of the district. 

[Ref. 2: p. 8-2]. The local net is not regarded as a piece 



of the IRM Architecture with systemwide impact 



E. SUMMARY 



We have given a brief overview of the Coast Guard's 
Information Resource Management Architecture, and 
established the central role of the Coast Guard District 
Office within that architecture. The present status of 
local networks for the district offices was examined; that 
"back burner" status is consistent with the C° Plan's 
perception of local nets as non-vital local utilities. 

The Coast Guard is still in the process of buying the 
equipment for the architecture, and at a rapid rate. That 
rate of growth is examined in the next chapter as an 
indicator that the Coast Guard will soon need to impose 
management controls on its servicewide information system. 
Later we will discuss the type of management controls best 
suited to an i n f o rm a t i on - p r oc e s s i ng system, and the 
advantages of prototyped development of those controls. A 
standard District Office Local Area Network, coupled with an 
auditable user authentication and access system, will be 
suggested as a mechanism crucial to adding management 



controls to the IRM Architecture. 



II. COMPUTER GROWTH IN THE COAST GUARD 



A. THE NOLAN MODEL 

One widely-accepted framework for understanding and 
evaluating data processing (DP) within organizations is 
Nolan's six-stage model for the introduction and growth of 
the data processing function within organizations [Ref. 4: 
pp. 76 -89 ]. Figure 4 illustrates the six stages and their 
characteristics within each of four "growth processes". The 
climbing dotted line represents the level of expenditures in 
the total DP budget for the organization. 

This model is a refinement of Nolan's earlier (1974) 
four-stage model based on the S-shaped curve described by 
most developing DP budgets [Ref. 5: p. 77]. The "transition 
point" of the later (1 976) model, shown in Figure 4 is the 
point at which a second S-shaped curve takes off. This 
occurs when the introduction of database technology causes 
renewed rapid growth of the DP budget. This later model 
assumes that initial applications do not employ database 
technology, and part of the increased expense after the 
transition point is for retrofitting that technology. This 
assumption may limit the expense curve's direct 
applicability to the Coast Guard IRM Architecture, given the 
C Plan's stated emphasis on widespread use of database 
technology from the beginning in all applications. The 



stages and general characteristics of the six-stage model, 
however, have been validated against experience with more 
than forty large corporations and should still apply to 
Coast Guard computerization [Ref. 4: p. 116]. 
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Figure 4. The Nolan Model of Organizational Computer Growth 

The process for placing a corporation's data processing 
within a particular growth stage involves two levels of 



benchmarks 



"The first step is to analyze the company's DP expenditure 
curve by observing its shape and comparing its annual 
growth rate with the company's sales. A sustained growth 
rate greater than sales indicates either a stage 2 or 4 
environment. If data base technology has been introduced 
and from 15% to 40% of the company's computer-based 
applications are operating using such technology, then the 
company is most likely experiencing stage 4." [Ref. 4: 

p.121 ] 

The second step involves evaluating the company's 
application portfolio against the investment benchmarks 
shown in Table II. "For instance, 80% support of 
operational systems, 20% support of management control 
systems, and just a faint trace of support for strategic 
planning systems would show the organization to be at stage 
3." [Ref. 4: p. 124]. 



TABLE II. Applications Portfolio Investment Benchmarks 



Stage 


Strategic 

planning 

systems 


Management 

control 

systems 


Operati 

systems 


1 


0 


0 


1 00% 


2 


< 1 % 


1 5% 


85% 


3 


< 1 % 


20% 


80% 


4 


5% 


30% 


65% 


5 


1 0% 


35% 


55% 


6 


1 5% 


40% 


45% 



B. BETWEEN CONTAGION AND CONTROL 

Trying to place the present growth stage of the Coast 
Guard IRM architecture is difficult, because there are no 
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accurate total IRM budgets prior to the establishment of the 
Office of C^. Many of the operational costs of the Coast 
Guard-owned record telecommunication system (for example, 
salaries) are still disguised as overhead expenses. Many 
powerful computers (up to and including mini -computers ) have 
been bought for word processing, and don't show up in the 
budgets of the comptroller-based DP departments. 

A rough approximation can be made by simply counting all 
computers, and assuming that in the early stages of growth 
expenses are linearly related to the number of available 
processing units. The graph in Figure 5 shows the growth in 
Coast Guard ADP equipment during the last six years, based 
on the Coast Guard ADP Equipment Inventory. This inventory, 
which GSA (the General Services Administration) requires 
every agency to maintain, represents a current census of any 
and all equipment including word processors, which performs 
or supports directly Automated Data Processing. The second 
curve in the figure shows only those units reported as 
containing a Central Processing Unit, i.e. a microprocessor; 
these are the actual 'computers' in the Coast Guard 
inventory, and they show the same rate of growth as the 
total hardware curve. Only 40% of the Districts had 
completed reporting their FY 83 figures at the time these 
statistics were compiled, but the figures as shown are 
characteristic of the Coast Guard in general. [Ref. 6] The 
fallof.f shown in the first curve may be a result of 
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incomplete reporting rather than the end of a hardware 
growth trend. 



USCG ADP EQUIPMENT GROWTH 




Figure 5. Coast Guard ADP Equipment Growth 

Comparing Figure 5 with Nolan's DP expense curve in 
Figure 4 places Coast Guard computer growth in Stage 2, the 
rapid expansion phase labelled 'contagion'. This assumes 
that the Coast Guard's total computer expenditures shows the 
same rapid growth illustrated for both total equipment and 
for CPU-equipped units. Since software is not reported in 
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the ADP Equipment inventory, the actual budget probably 
shows a higher growth rate than illustrated. 

The second step in the placement method is a look at the 

organization's applications portfolio. Table III is a 

listing of Major Information Projects of the Office of 

3 

Command, Control and Communications, taken from the C 
Support Program Plan [Ref. 2: p. 10-1]. Each project has 

been categorized by the organizational level it primarily 
affects. Eleven of these fourteen initial computer projects 
benefit or improve operations directly. Three of the 
fourteen improve or support management control. According to 
Nolan's investment benchmarks in Table II, these figures 
place the applications portfolio in stage 3, the control 
stage. The current state of the Coast Guard IRM 

architecture is therefore between contagion and control. 

The rapid growth in stage 2 starts with the spectacular 
successes of the initial computerization efforts during 
stage 1. The excess computer capacity usually acquired 
during the first phase, coupled with the lure of broader and 
more advanced applications, triggers a period of rapid 
expansion. Stage 2 represents a steady and steep rise in 
expenditures for hardware, software and personnel. It is a 
period of contagious, unplanned growth characterized by 
growing responsibilities for the EDP director, a loose 
(usually decentralized) organization of the EDP facility, 
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and few explicit means of setting project priorities or 
crystallizing plans. 



TABLE III. List of Major Office of C 3 IRM Projects 



MAJOR PROJECT 


CATEGORY 


Marine Safety Information System 


Operational 


Joint Uniform Military Pay System 


Operational 


Telecommunications Study - Combine 
Computer and Record Comms 


Operational 


Office Automation 


Operational 


Command Centers 


Operational 


District Minicomputers 


Operational 


Shipboard Assisted Maintenance 
Planning (SCAMP) 


Operational 



Yard/Supply Center Inventory Control 



Point Acquisition 


Operational 


G-T Office Budget System 


Management Control 


Coast Guard Standard Accounting 
System 


Operational 


User Responsibility ( Chargeback ) 


Management Control 


Data Management 


Management Control 


Cobol Conversion 


Operational 


Operations Computer Center 


Operational 



This stage often ends in crisis when top management 
becomes aware of the explosive growth of the activity and 
its budget, and decides to rationalize and coordinate the 
entire organization's EDP effort. The dynamic force of 
expansion makes this a fairly difficult thing to do, 
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however, and the growth seems to be continuing unabated. Top 
management frequently concludes that the only way to get 
control of the resource is through drastic measures, even if 
this means replacing many systems analysts and other 
valuable technical people who will choose to leave rather 
than work under the stringent controls that are imposed 
during the stage. Firing the old EDP manager is by no means 
an unusual step. 

Often what was a decentralized function and facility is 
rather suddenly centralized for better control. Often 
informal planning suddenly gives way to formal planning, 
perhaps arbitrarily. This stage frequently includes the 
first formalization of management reporting systems for 
computer operation, a new chargeback system, and the 
establishment of elaborate and cumbrous quality-control 
measures. In short, action taken to deal with the crisis 
often goes beyond what is needed, and the pendulum may swing 
too far. 

Based on his studies of corporations weathering these 
computer transition stages, Nolan indicates that for the 
most part, the problems that arise toward the end of Stage 2 
can be greatly alleviated by introducing right at the start 
of Stage 2 the techniques that companies ordinarily use in 
Stage 3." [Ref. 5: pp. 79-83 ] 

These Stage 3 controls are shown in Table IV as they 
were presented in the earlier four-stage model. Also 
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Loose Budget Loose Budget Strong budgetary planning Multiple 3-4 year plans for 

for hardware facilities . hardware, facilities, perso 

and new applications. nel , and new applications. 



significant in this figure are the Stage 4 controls, 
specifically the data base policies and standards and the 
focus on computer services pricing for effective use. Later 
we will see that these Stage 4 controls are the type which 
the Plan would like to implement directly. For now the 
major points are that the architecture is approaching the 
control stage, and the early introduction of controls can 
greatly ease the crisis nature of the transition to Stage 3. 

In the next chapter, we will examine the concept of 
control generally, and the types of controls available for 
information systems. Some specific recommendations will be 
made for management controls consistent with the Coast Guard 
IRM Architecture. 
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III. MANAGEMENT CONTROL OF COMPUTERS 



A. CONTROL IN GENERAL 

Management control is a cycle that includes the three 
stages of goal setting, performance evaluation, and feed- 
back. These three stages of control are illustrated in 
Figure 6. (1.) Goal setting involves planning, and 

establishing the goals required for desired performance 
levels. Measuring and monitoring functions record actual 
performance. (2.) Performance evaluation compares 
performance reports with goals. (3.) Feedback information is 
designed to make corrections in either goals or work 
activities to bring them into alignment. [Ref. 7: p. 310] 




Figure 6. Management Control Stages 
This cycle forms the heart of management control systems in 
most businesses, with the department or division budget 
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quantifying most of the goals, and the quarterly financial 
statement providing the performance information to be 
evaluated against the budget's projections. 

B. CONTROL AND CHARGEBACK UNDER CENTRALIZED EDP 

Although the expense and the technical complexity of 
computers has sometimes obscured the point, this general 
model of management control can be applied to control an 
Electronic Data Processing department as directly and as 
well as any other department. Top management has two main 
concerns in controlling the EDP department: 

1. Are we spending too much, or too little, or just 
enough on EDP? 

2. Is the money we have allocated to the department being 
properly spent? 

To answer these questions, and control EDP, top manage- 
ment needs two key structures. The first is a financial 
reporting system that allows it to do the following things: 

1. Review the department's performance on a periodic 
basis . 

2. Compare the department's development against the 
formal plans for it. 

3. Check the functioning of the department's project 
control systems. 

The second is a structure that links the responsibility 
for various departmental decisions to the operations of the 
users--ordinarily other company departments. Generally, this 
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structure is a procedure to account for EDP expenses, either 
on a charge-out or an overhead basis. [Ref. 8: pp. 70, 83 ] 

As in other business activities, the key performance 
reporting information is financial; for EDP it is used to 
track both the department's performance against its own 
goals (department budget and project control system), and 
the degree and mix of its support to the other departments 
(chargeback system). Two weak spots in financial control 
systems for EDP departments have been project control for 
software development and user chargeback systems based on 
computer resources and terminology. Developments in software 
cost estimation, like Boehm's COCOMO (Cost Control Model), 
and techniques like structured programming and programmer 
teams have greatly reduced the difficulty of estimating and 
controlling software development projects. Computer-oriented 
chargeback systems which give users detailed reports of the 
CPU-seconds, main and secondary memory units used, etc., are 
gradually being displaced by user-oriented systems as 
computer services become crucial to the "bottom line" of 
most operating divisions. The reasons for these new systems 
will be discussed later. 

The financial basis of management control of EDP 
departments has two important implications: 

1. As a general rule management control systems for data 
processing cannot be significantly more advanced than 
the management control systems used for the company as 
a whole. Since accounting systems provide the 
foundation for management control, management control 
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can only reflect the quality of the accounting 
system." [Ref. 9: pp. 311, 315] 

2. The development of data processing accounting systems 
is initially an accounting problem rather than a data 
processing problem because basic accounting concepts 
are most important. Unfortunately, this need for 
accounting skills is not recognized from the start. 
Usually, technical personnel play the dominant role in 
designing the initial DP accounting systems. Rather 
quickly, however, it becomes apparent that the real 
problems are financial accounting problems concerning 
responsibility centers, costing, and allocating costs 
to responsibility centers. Accounting personnel are 
then brought into the project. 

These fundamental problems seriously hinder the 

effective design, implementation and administration of 

computer use chargeback systems. Simply stated, you cannot 

build a sophisticated control system on a sandy foundation 

of weak accounting systems. [Ref. 9: p. 315] 

1 . Evolution of Chargeback System s 

Computer chargeback systems were originally 

accounting devices to allocate the costs of a very large 

capital investment among the departments that used it. When 

most of the processing was large batch jobs, a relatively 

simple system could price batch jobs according their use of 

computer resources, as reflected in reports from system 

monitor programs. 

Differential pricing began as an efficiency measure, 
to boost use and distribute the workload on the computer 
more evenly by charging less for jobs run during the evening 
and night shifts. Once the computer was fully scheduled 
(and more) it became a scarce resource; prices were further 
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differentiated, and coupled with a priority system for the 
jobs themselves, to control and monitor the competition for 
the now-scarce computing time. 

An important transition was made as the 
organization's goals changed from efficient (full use) to 
effective (most necessary jobs) use of the computer system. 
The management control purpose of the chargeback system was 
expanded to include shaping the behavior of users. 
Information not necessary to proper computer operation, i.e. 
job class and priority, was added to jobs and the operations 
monitoring programs were changed to record it. The range of 
choices available to the user department grew, but the costs 
of those choices were determined by the EDP department, and 
still largely based on recovering the actual costs of 
equipment and operations. 

A priority system and a single scarce resource 
implies that some jobs never get scheduled. An alternative 
to the central EDP department came about as decreasing 
equipment costs allowed time-sharing and computer service 
bureaus to develop, and it became theoretically possible to 
get all computer projects accomplished without a major 
capital investment decision. Rather than competing for use 
of the single company computer, projects could be subjected 
to the same cost/benefit analysis used for other business 
projects in the firm. For the first time, make-or-buy 
analysis (whether to do a job yourself or buy it from 
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someone else) could be applied also. This open market of 
competition to the central ED P facility radically changed 
the management control uses of the chargeback system again. 
An open market fosters competition through price, and allows 
the chargeback prices to be used to judge how ef f icientl y 
the EDP department delivers computer services. The 
responsibility for e ffective use of computer services was 
almost totally transferred to the user departments, as the 
organization's experts on the business benefits of a 
particular application. Currently organizations require the 
chargeback system to isolate as completely and clearly as 
possible, the actual costs of the specific application. The 
prices must be refined to eliminate the variances due to the 
operation of the computer department from the actual 
consequences of the "consumer's" use. This provides to the 
user the best cost information with which to make a sound 
cost/benefit decision for the company. Chargeback is also 
used to evaluate the user for efficiency in the use of 
computer resources in accomplishing his or her business 
mission . 

Both the financial accounting and the computer- 
resource accounting abilities of the organization have had 
to mature to accomplish the expanding management control 
purposes of chargeback in an increasingly complex 
environment. As the responsibility for effective and 
efficient uee of computing resources shifts to the user 
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departments, they have demanded that charges be expressed in 
units they can understand and effect. Applying industrial 
accounting techniques allows the allocation of the resource 
costs per job (CPU-seconds , tape and disk drive hours, main 
and secondary memory) to be priced out as standard costs per 
work unit (cost per check, per invoice, per personnel record 
update). These standard costs can be accumulated by section 
or office within a department to support a finer degree of 
control . 

The implementation of management control through 
chargeback is a dynamic process. Studies of the process have 
developed four criteria for judging chargeback systems: 

1 . Understandability : 

To what extent can the manager associate charge-out 
costs to the activities necessary to carry out his or 
her tasks? 

2. Controllability: 

To what extent are the charges under the control of 
the user? 

3. Accountability: 

Are costs and utilization of computer-based systems 
included in the performance evaluation of the user? 

4. Cost/benefit incidence: 

Does the user responsible for task accomplishment also 
receive the chargeout bill? [Ref. 9: p. 317] 

In addition to evaluation criteria, these studies 
have produced several vital general observations. One 
mistake frequently observed in designing an effective system 
is to impose sophisticated controls upon organizational 
units that are not "ready". The organization unit is not 
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ready if controls hinder its operation or if personnel 
cannot clearly see the relevance of the controls to their 
problems. [Ref. 9: p. 311 ] 

Chargeback systems also evolve. They initially are 
directed at high-level managers. Summary data processing 
bills are sent to divisional controllers without much 
information on the charges being conveyed to end users. With 
maturity, the charge-out systems become more sophisticated 
and permit detailed bills to be sent directly to low-level 
users. It is important that a chargeback system does evolve 
through successive phases so that users and DP managers can 
learn how to interpret and use the information. It is 
especially important that the means for accountability be 
coordinated with the expectations for accountability. Users 
resent charges for systems they cannot affect. 

Management's objective is to develop a strategy that 
will increase the maturity (and effectiveness) of the 
charge-out system at an appropriate pace for the major user 
groups. It is likely that several charge-out strategies may 
be required for the different user groups. [Ref. 9: p. 318] 
2 . Summary 

In the process of developing management controls for 
the Coast Guard IRM architecture, the lessons we can 
transfer from the experience of centralized EDP include: 

1. Management controls for EDP are financial in nature 
and thus comparable to the controls on other 
departments . 
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2 . 



They have a stronger base in good accounting than in 
technology. They can therefore be no more complex than 
the accounting and management control systems of the 
rest of the organization. 

3. A chargeback system is essential to management control 
of EDP departments, and eventually, EDP users. 

4. Chargeback schemes grow and mature. Management must 
develop a strategy to manage this process at an rate 
appropriate to the major user groups, and to changing 
management control needs. 

An important although not obvious point is that the 
competition for computer services described here takes place 
in essentially a single arena. The goods and services 
(reports, database queries, CPU cycles) are almost perfectly 
interchangeable, between the daytime on-line version of the 
payroll and the late shift batch run of the same program, 
even between the in-house product and the service bureau 
version of the same printout. Competition by price is a 
logical basis of comparison of substitutable goods in the 
same open market, whether in keeping the EDP department 
'honest', or in the user's trade-off between alternate ways 
of implementing a given project. As a management control 
technique, it assumes that everyone knows all the prices 
(perfect knowledge) and knows the substitutability of 
various goods, so changing the relative pricing should 
logically effect behavior. 

C. EXPANDING EDP TO IRM AND REFINING CHARGEBACK 

Information resource management obviously entails more 
than controlling a centralized data processing center. The 
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Coast Guard has defined it to include all information 
processing: transactional and operational information, 

office automation as well as data processing and voice and 
data telecommunications. This expansion means it includes 
what Strassman defines as a second major sector of 
information processing, "administrative processing", which 
he says is largely ignored by i n f orm a ti on -proce s s ing 
executives : 

"While it accounts for the largest and most frequently 
used set of tools and facilities for handling information 
transactions, it is rarely aggregated under a single 
expense heading. It includes everything from typewriters, 
word processors and dictating equipment to telephone and 
Telex networks, recording devices, copiers and duplica- 
tors, facsimile transmission devices, microfilm equipment, 
and even such relatively mundane necessities as office 
supplies, mail, and simple filing systems. These adminis- 
trative tools are quite diverse and often isolated from 
one another, so that the expense involved in their use 
tends to become highly diffused. Historically, little 
trade-off has been possible among such individual office 
"technologies". [Ref. 9: p. 2 95 ] 

No organizational unit is responsible for integrating 
these noncomputer aspects of information handling, but the 
fastest expense growth in the office environment is 
occurring here. If an organization intends to control rising 
expenses for 'white-collar automation', information systems 
management must expand to include careful expense accounting 
for these diverse office technologies. This control must 
also be in some flexible automated form, since the future 
volume of information transactions is uncertain, as are the 
relative importance of various cost elements, rapid changes 
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in technology, and shifting attitudes toward office 
automation by labor and government. [Ref. 9: p. 296] 

In addition to the increased size of the total 
information system, and a greatly increased number of 
transactions, we are annexing an area where the costs are so 
spread out as to be hard to accumulate. The management 
control job will be further complicated by the lack of 
direct tradeoffs between the products of some of the 
subsystems in the architecture. For a price-based control 
system to work, some indirect measure of substitutability 
among the systems will have to be developed. Considering the 
massive volume of transactions, the entire control system 
must be eventually completely automated. It is more 
appropriate to call it an 'information pricing system' 
rather than 'chargeback'. A good encapsulation of the 
ultimate goals of such a control system is Strassman's list 
of the objectives for a top information executive in today's 
business environment: 

* Ensuring the integration of data processing, adminis- 
trative processing, and office labor productivity 
programs . 

* Instituting accounting, cost-control, and budgeting 
innovations that will subject all information systems 
overhead activities to the disciplines traditionally 
applied to direct labor. 

Subjecting office labor automation programs to 
analyses comparable to those applied to all other 
forms of capital investment. 

Conceiving organizational designs that will permit 
information to be handled as a readily accessible and 
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easily priced commodity rather than as a bureaucratic 
possession . 

* Creating within the organization an internal market 
for alternative information systems products, so that 
trade-off decisions, even technologically complex 
ones, can be decentralized into the hands of local 
user management. 

* Fostering a technique of pricing that will allow 
decisions on introducing new technology, or abandoning 
obsolete technology, to be made on a decentralized 
basis . 

* Installing and monitoring measurement methods that 
will protect improvements in productivity achieved by 
automation programs. 

These are the ultimate, not the immediate, goals of any 
proposed management control system for a complete informa- 
tion system. By examining the purposes and evolution of EDP 
chargeback, and projecting the requirements for information 
systems control for the future, we have set the stage for 
considering specific recommendations for management control 
requirements of the Coast Guard Information Resource 
Management Architecture. 
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IV. CONTROL REQUIREMENTS OF THE ARCHITECTURE 



A. SUGGESTED MANAGEMENT CONTROL REQUIREMENTS FOR THE COAST 

GUARD INFORMATION RESOURCE MANAGEMENT ARCHITECTURE 

To pave the way for a smooth transition to the control 
stage of computer growth, the Coast Guard should soon 
develop the information or systems necessary to meet the 
following five requirements: 

1 . Aggregate financial information 

2. Auditable identification of users 

3. Meaningful chargeback system(s) 

4. An 'information marketplace' 

5. An information decision-making tool 

Each of these will be explained in detail below. These 
suggestions assume that major hardware subsystems ( i .e . 
mainframe or minicomputers, communications network 
interfaces) will have resource-accounting monitor programs 
installed . 

1 . Aggregate Financial Information 

Since the primary support of budget-based management 
control systems is good accounting, the Coast Guard 
accounting system should be modified to allow for 
information costs to be aggregated, both by organizational 
unit, (i.e. a Division or a Section of a District Office) 
and by a project identifier (Project D17-21, Develop 
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Operations Database). The current joint project of the 
Office of and the Office of the Comptroller to develop 
and automate a Coast Guard Standard Accounting System should 
address whether a separate Operating Guide (OG) or a Subhead 
is needed to identify information funds, or whether an 
Object Code identifier holds enough information and 
flexibility for complex financial reporting. A unique 
identification of the funds as information funding, along 
with a system or project identifier, and a capability to 
retrieve by organizational subunit will support the reports 
necessary to monitor and control both the IRM function and 
the end users. An identifying field of this sort would 
support "information budgets" easily when cost control 
becomes necessary. It also would function partially as a 
common denominator for the information services, supporting 
tradeoff decisions and preserving information savings for 
the i n f o r ma t i on - e f f i c i en t manager to spend on other 
information services. 

2. Auditable Identification of Users 
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authorization and identification structures used in the 
various subsystems of the IRM Architecture be auditable, 
that they maintain or can reconstruct a complete audit trail 
from end user to ultimate database. 

In addition to insuring auditability of IRM 
financial accounting and chargeback, an auditable user 
identification scheme reinforces system security, and by 
increasing the perceived threat of apprehension, strengthens 
the policy and procedure controls of the system. Another 
perception that benefits from secure identification is the 
perceived equity of the chargeback system. Since not all 
users nor all applications can be equally important to the 
organization, the most a chargeback system can hope for is 
"perceived equity". [Ref. 10: p. 260] An auditable access 

scheme documents for the user that the charges received did 
originate in his/her department, and reinforces a perception 
of equity. 

The high degree of telecommunications in the IRM 
Architecture, with some systems open to several networks, 
means that simple password systems will not provide adequate 
protection. This communications vulnerability is aggravated 
by the periodic transfers of the Coast Guard's military 
personnel. User accounts are often only logical partitions 
in the same computer, accessed by a network common to 
several physical user sites. Passwords could not protect a 
filespace from an old authorized user at a new duty station. 
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Some hardware identification (such as a terminal identifier) 
at least needs to be added to all systems. To preserve the 
audit trail, space for this terminal identifier and the user 
i.d. needs to be designed into network message headers. Once 
the access and message header configurations are frozen, the 
incremental costs of adding security and auditability will 
be much higher, as will the temptation to forego the expense 
and rely on procedures alone for control. 

3 . Meaningful Chargeback System ( s ) 

The goals of a meaningful chargeback system are to 
express the costs of information in the terms of the user's 
units of work, and to understandably identify, accumulate, 
and return to the user all information costs associated with 
his/her work operations. Ultimately, such a system would 
completely satisfy all four of the evaluation criteria 
listed in Chapter III. The system administrative overhead 
necessary for the financial reporting and user 
identification requirements just discussed will also enable 
a u se r- or ient ed chargeback system to be implemented, as a 
third benefit to offset those same costs. 

One possible implementation of such a chargeback 
scheme is as an interface accounting program, which would 
accept inputs from the various subsystems, sort them by user 
identification, cross reference with user budgets and 
transaction totals, and produce a average cost per 
transaction type, detailed to identify information subsystem 
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costs. Such a system would have to be both modular and 
flexible by design, to allow subsystems to be added and 
removed as configurations and technology changed. Locating 
it as close to the user as possible in the architecture 
would allow all higher systems to run "off-the-shelf" 
computer resource monitors, modified only enough to record 
both user and terminal identifications. 

4 . An Information Marketplace 

Users could make trade-off decisions rather easily 
when the services were all available from one source (the 
EDP department), or even were direct substitutes for each 
other (service bureau versus in-house, for the same 
product). The number of alternative information services, 
and the number of ways to obtain them are both growing 
rapidly, even within the unifying device of the IRM 
Architecture. Strict dollar cost is not an accurate basis 
for comparison or competition any longer. The Support 

Program Plan identifies timeliness, quality (accuracy and 
precision), quantity, and cost (of collection, transmission, 
storage, and use ) as components of information of interest 
to the Coast Guard [Ref. 2: p. 5-1 ]. Few among user 

management will have the information judgement to evaluate a 
straight cost for service against its value along those four 
parameters. Some set of adjusted prices, or factors by 
which to weight costs will be necessary to create an 
information marketplace where products and services of the 
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various information subsystems can be directly compared. 
The user is the expert on the benefits to his program that 
the service will provide; the architecture will have to 
provide him/her a basis for properly comparing and 
evaluating the costs of that service, if the Coast Guard 
intends to hold the user accountable for an effective and 
efficient decision. This could be as simple as a set of 
adjusted prices for a generic example, (i.e. the average 
letter costs 2.6 times as much as a message) coupled with 
substitution rules and judgement criteria (letter vs 
message: consider speed and security), or as complex as a 
database of currently-calculated weighting factors available 
to an automated decision-making tool. 

5 . An Information Decision-making Tool 

In addition to creating the information marketplace 
by publishing a list of adjusted or general substitution 
prices, the system should provide a consumer's guide to 
proper shopping. This will insure the most effective 
accomplishment of the IRM architecture's management control 
mission through pricing and chargeback. 

It is to the Coast Guard's advantage to have users 
making the most effective and efficient information 
decisions possible. The user/manager is best qualified to 
make the cost/benefit comparison of alternative information 
services. The goal of the chargeback system is to provide 
that user/manager the best possible cost information to 
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combine with his best possible benefit knowledge, and then 
hold him accountable for the decision. The manager will 
develop an information decision 'support system' for these 
decisions, if only a set of notes on how the last one was 
done. There will be a faster learning curve and more 
consistent results if the IRM architecture recognizes this 
and supports the manager's decision by some standard means. 

A published set of suggested procedures (cookbook 
guide) could couple with a price list to produce trade-off 
decisions standard enough to be comparable and reproducible. 
Eventually, a spreadsheet program able to access a 
substitution price table, or to calculate weighted prices 
from the chargeback information could be developed. Some 
project lifecycle guidelines could be incorporated in such a 
program painlessly. In whatever manner, some decision 
support should be developed. To have management control 
through pricing and chargeback work properly, we assume the 
goods are substitutable, and the consumers have perfect 
knowledge of both price and substitutability. We further 
assume they will make the logically best choice. These last 
two suggestions for the IRM architecture (information 
marketplace and decision support) attempt to insure those 
assumptions are met, and to assist the user in the choice 
best for his unit and for the Coast Guard. 
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B. IMPLEMENTATION SUGGESTIONS 



1 . The Standardized User Interface 

In a system as large and as distributed as the Coast 
Guard IRM Architecture, operating under Federal rules for 
competitive procurement, it is almost certain that the 
various subsystems (both hardware and software) will be 
developed separately. Unless specifically controlled, the 
interface each subsystem presents to the user will vary from 
one subsystem to another. The interface includes such things 
as the location and size of text, the method of specifying 
commands (numbers, letters, words), the method of presenting 
options (text or a menu) and other guidelines to the user 
for input. 

At the extreme range of variation of these inter- 
faces, an identical command will have different meaning and 
effect in two different systems which a single user 
routinely accesses. (For example, STOP in one system halts 
text scrolling on a display screen, in another it ends the 
session . ) 

Specifying a standard user interface- to be 
maintained by all subsystems simplifies learning and use of 
the entire coordinated system greatly. It provides a 
mechanism for the smooth introduction of change as well, by 
preserving for the user as much of the familiar as possible 
as an environment for the new function or command. A major 
advantage is that once an effective user interface for a 
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given system or subsystem is developed, that design can be 
'frozen' from change for a while, preserving the 
effectiveness of the interface through other system changes. 
We have seen that chargeback and management control systems 
change to match the maturity and growth of the information 
system overall. Expecting that change, a standard user 
interface should be developed and incorporated in all 
automated portions of the control structure of the IRM 
architecture . 

2 . Prototype /iterate/ Adapt 

We have already characterized portions of the 
proposed management control structure for the IRM 
architecture as a decision support system for the user in 
purchasing information services. That tool could also 
function as a decision support system for the organization 
in choosing those prices which will produce the desired user 
behavior. A proposed new price for a single service could 
be tested by running the user's decision tool program with 
that price as an input. The price could be adjusted until 
the desired decision was reached, or the model could be run 
'backward' to determine the specific price change required. 
Developing the Coast Guard IRM management control structure 
shares much with the development of decision support 
systems, as characterized by Keen [Ref. 11: p. 132]: 

Neither the user nor the builder can specify 

functional requirements in advance. 
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* Users do not know, or cannot articulate what they want 
and need. They need an initial system to react to and 
improve upon. 

* The users' concept of the task and perception of the 
nature of the problem changes as the system is used. 

* Actual usages (of DSS ) are almost always different 
from the original intended ones. In fact case studies 
show that many of the most valued and innovative uses 
could not have been predicted when the system was 
originally designed. 

* Intended users of the system have sufficient autonomy 
to handle the task in a variety of ways, or to differ 
in the way they think to a degree that prevents 
standardization of process. 

Several studies [Refs. 12, 13, 14] suggest that the best 

method for designing a system in such a loosely-defined 
situation is by an iterative design process. The steps in 
the process include: 

1 . Identify an important subproblem. 

2. Develop a small, but usable system to assist the user. 

3. Refine, expand and modify the system in cycles. 

4. Evaluate the system constantly. 

This design approach starts with an prototype system, which 
adapts in successive iterations to the user's and the 
designer's experiences. By definition it is flexible and 
adaptable. This method is proposed as a design alternative 
to classic system life cycle design, which attempts to 
define all possible system requirements in the initial study 
phase, and then delivers a specific system to satisfy those 
requirements. A major change in such a system requires a 
return to the study phase and a new set of requirements. An 
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advantage of iterative design is that several different 
small prototypes can be run in parallel, and evaluated 
before selecting a standard model for system-wide 
implementation testing. 

The various programs and systems to satisfy the 
management control requirements previously listed, with the 
single exception of the structure for aggregation of 
financial information, should be developed using this 
iterative design methodology. The complex and ill-defined 
nature of the control problem, plus the need for the control 
system to continually grow, support using a method focused 
on development of poorly defined and flexible systems. 

The appropriate place to initially install the prototype 
systems to begin satisfying the proposed management control 
requirements is at the level of the District Office, for a 
number of reasons which will be fully developed in the next 
chapter. An implementation incorporating several of the 
necessary control elements into a District Office Local Area 
Network will also be described. 
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V. THE DISTRICT OFFICE LOCAL AREA NETWORK 
IMPLEMENTATION OF MANAGEMENT CONTROLS 

A. WHY THE COAST GUARD DISTRICT OFFICE 

The major reason for placing the management control 
structures of the Coast Guard IRM architecture at the level 
of the District Office is to remain congruent with the rest 
of the organization. The District Office exercises manage- 
ment control over every other operational program and staff 
function. In the financial chain, for example, the District 
Comptroller approves operating unit budgets with the 
concurrence of the district program manager. For 
administrative information control, all official 
correspondence and reports enroute from operating units to 
Headquarters must be endorsed by the district program 
manager in the chain of command for the originating unit. 
Management control of the information program logically 
belongs at the District Office as well. 

The District Office is the level at which hierarchical 
information is aggregated for forwarding to Headquarters, as 
illustrated in Figure 3. The Coast Guard District block in 
the IRM architecture (as illustrated in Figure 1) is also 
the system node with the most connections to other networks 
and units. This center of connectivity is the best place to 
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easily collect a maximum amount of data about computer and 
communication systems usage. 

With the installation of minicomputers in each of the 
twelve Coast Guard Districts scheduled for FY 86, the 
processing power will be available to run the monitor, 
accounting and user identification programs necessary to the 
prototypes. There will also be sufficient data storage 
capacity available to accumulate an historic data base on 
usage and usage patterns for information services. 

People resources are at the District Offices as well. 
The District IRM officers are in place with the knowledge to 
run and evaluate the prototype control systems. The other 
district program managers make up a team of knowledgeable 
control-oriented managers ready to fully test the various 
prototypes and suggest changes. Because of these program 
managers, the IRM control problem at the District office 
will be the most difficult, and therefore the richest in 
terms of potential learning about user requirements. 

The district program managers are management controllers 
themselves, of units and programs for a geographic area. A 
major mission of the district IRM staffs will be teaching 
them how to use information services in exercising that 
management control. As the need for control of the IRM 
architecture grows, the district IRM staff's job will become 
controlling these other controllers, and through them their 
units,- to promote more efficient and effective use of 
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information services. The district IRM office is the turning 
point at which control within the vertical structure of the 
information program (the IRM architecture) must translate 
into horizontal control (by the district IRM staff) of 
resource distribution and use out to the district managers 
of other programs. They are the logical office to task with 
calculating and distributing the chargeback bills to the 
district program managers, both for information services 
received from the District, and for an allocated portion of 
other services (i.e., HQ database usage) being billed to the 
District. These bills will be a primary control device of 
the architecture. The user is understandably apt to feel 
unfairly treated when the people who developed and fed his 
growing dependence on information services begin blaming him 
(holding him cost responsible) for overuse of those same 
services. Early placement of the control structures would 
allow tactics such as distributing 'educational' chargeback 
bills which remind users that they are not using a free 
good. It would also make a usage history available when the 
first aggregated chargeback bills to the District show up 
from the Headquarters databases, to substantiate equitable 
apportionment of the cost by the District IRM staff. 

The District Office is the node of the Coast Guard IRM 
architecture where it all comes together. Satisfying the 
management control requirements of that architecture at the 
District Office level is the crucial problem for control of 
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the architecture overall, and an early start on the problem 
may ease a difficult transition from teacher to tax man for 
the district IRM staff later on. 

B. WHY THE LOCAL AREA NETWORK 

Throughout the thesis we have been attempting to develop 

the need for, and requirements of, management control 

structures for the entire Coast Guard IRM Architecture, as 

one large but integrated system. That integration is an 

express intention of the Office of C^: 

"The IRM architecture and other policies of the (Office of 
) program discourages the proliferation of field-unit 
terminals connected independently to s i ng le - program 
central data bases. This would be an electronic version 
of our present uncoordinated, overlapping, manual 
information system." [Ref. 1: pp. 4-7] 

While the management control requirements we have 

developed are applicable and useful to any of the single 

vertical information systems within the overall architecture 

(e.g. Personnel Management Information System (PMIS), Marine 

Safety Information System (MSIS)), they are also powerful 

devices for logical integration of these separate systems 

into a single architecture, from the user's point of view. 

To accomplish this integration, the controls must be 

applied, or at least appear to the user to be applied, as a 

single part of a unified architecture. 

To those who have read the various planning and support 

documents of the IRM architecture, it is a logical whole, 

and its integration of systems is obvious. However, if the 
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user of the system confronts a different interface screen 
and different sign-on procedure for each of the subsystems 
(PMIS, MSIS) he or she uses, and if each of these subsystems 
returns a separate chargeback bill which the user must 
"integrate" with a hand calculator, then the IRM 
architecture has not achieved its 'single system' goal. 

The single physical device connecting all the 
information resources of the CG District block, in the 
Figure 1 illustration of the architecture, is the 'local 
net', the District Office Local Area Network (LAN). When 
fully operational, this local net will be the port through 
which all district information services can be accessed. 
Application of the IRM architecture's management controls 
through the LAN uses its physical integrating power to 
create and reinforce the logical unity of the overall 
system. It collects the separate shopkeepers of the 
individual information systems into an information 
marketplace where control through pricing can be most 
effective for the entire architecture. 



C. MEETING THE REQUIREMENTS WITH THE LAN 

Each of the management control requirements will be 
discussed separately below for a configuration that assumes 
an operating local area network is in place. 
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1 . Aggregate Financial Information 



While no physical program or device is needed to 
satisfy this requirement, the necessary changes to the 
financial accounting structure will need to be defined 
before the design configuration is frozen for other, 
automated portions of the control structure. The accounting 
changes may add extra data items, or expand the size of 
existing data items, throughout the architecture, to ensure 
that the information necessary for the audit trail and for 
pro j ec t - le ve 1 aggregation of information costs is 
maintained. For example, adding a field to a message header 
to hold a project identification may change hardware and 
software throughout the system. 

2. Auditable User Access 

The District LAN is the IRM system entry port; user 
and terminal identification should be demanded and tested 
here. This begins and maintains the audit trail at the point 
of first entry for all users at or below the District Office 
level. Once the user is authorized access to the network, 
the network can then access all subsequent communications 
links and computers, providing the appropriate access 
information and identifying the user and terminal to the 
other systems. 

This eliminates the problem to the user presented by 
a multitude of different access procedures for each of the 
different intermediate services. For example, to access the 
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Operational Information System computer in New York, the 
user must dial the local number of GTE TELENET, and comply 
with their sign on procedures, providing an account number 
and a password, then requesting the connection. Once 
connected to the OPINS computer, a minimum of three more 
i.d. and password combinations are necessary to reach a 
working level successfully. The importance of the informa- 
tion involved justifies the security, but the tedium to the 
user has prompted the OPINS configuration managers to 
authorize an programmable modem (computer communications 
device) to be installed in their systems. This modem then 
allows a user to access the remote computer with the push of 
a single button. The protocols, identification numbers and 
passwords are all programmed into the modem, and 
automatically presented to the necessary subsystems. The 
audit trail is lost--the system cannot record a unique 
identification (number, password and terminal i.d.) of 
whichever user pushes the button. Satisfying the 
requirement for auditable user identification at the initial 
access to the District LAN would preserve the utility of 
automation such as this while not losing security or 
auditability. Overall system security would actually 
increase by recording the user identification data provided 
to the LAN by people repeatedly attempting access to systems 
for which they were not authorized. 
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This automation provides more than user convenience. 
The various information subsystems ( PM IS, MSIS) are reached 
via different communications networks, and once accessed 
have different password procedures and file structures. If 
the user must record and maintain the access information for 
each system separately, then the fact of their separateness 
as subsystems is reinforced each time any subsystem is 
accessed. If the various subsystems all appear as selections 
on an "Access Menu" once the user has signed on to the LAN, 
they are reinforced as parts of a unified system. 

One alternative to LAN user identification data 
capture is distributing unique identifiers and passwords for 
all individual units at the destination end, (i.e. OPINS) 
and auditing use for chargeback there. Administering both a 
billing and a password maintenance system adds 
administrative overhead at the highest level of the 
architecture. Collection of the usage data is removed from 
the level of enforcement of the charges, and the user's 
perception of autonomy and system equity may suffer. 

3 . Meaningful Chargeback System 

A meaningful chargeback system provides information 
useful to the user. While the initial chargeback systems 
will not be refined enough to track each user in detail and 
express all costs in terms of the user's work units, the 
'useful information' goal can be preserved during the 
iterative development of the chargeback system, and this 
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function, too, can reinforce the concept of unity for the 
architecture . 

For example, consolidating and keeping track of the 
separate information service charges against a user 
division's total information budget (telephone. Xerox, 
microcomputer supplies and maintenance, etc.) would be 
useful to the user while reinforcing logical integration of 
these (now) diverse services. A program available through 
the network to extract such accounting data for a given 
user, producing an up-to-the-minute status for his/her 
information budget would do much to associate resource 
accounting with information rather than bills. Such a 
program would only require a standard query to the 
accounting database on the District minicomputer. Having the 
program available through the LAN allows IRM managers to 
track how frequently the program is used, as a rough guide 
to the 'information awareness' of the entire staff or a 
given division. 

Often, before actual charges for system use are 
levied, the chargeback system is used as a device to notify 
users of the level and cost of the information service they 
consume. [Ref. 15: p. 114]. As each of the various 

subsystems gains resource accounting and reporting 
capabilities, their usage data could be added to the 
chargeback or 'budget status' report. The transition to 
actual charges would be a gradual change, and the user could 
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judge both charges and usage data in context. The single 
budget report (bill) would reinforce the logical system 
unity, and the LAN could make it a recordable and easily 
accomplished event. 

4 . An Information Marketplace/ Dec is ion Tool 

The marketplace concept is an attempt to identify 
the functions and costs of the information services, and to 
identify the substitutions possible between them. It intends 
to develop in the user a holistic view of information 
processing and to influence his/her conduct with pricing. 
If functionally similar services are available through the 
LAN as a series of substitution lists or function menus, the 
physical presentation strongly reinforces the logical 
integration and substitutability the management controls are 
trying to develop. Rather than remembering that electronic 
mail and/or record communications messages can substitute 
for hard copies on letterhead stationery, the user chooses 
one or the other from an "Output Menu" and the network 
delivers the user's document to the appropriate device. Or, 
the user could select several options and compare their 
prices before committing the document for delivery. The 
decision tool could be incorporated as a "How Much?" command 
available to compare possible choices in terms of 
information dollar costs. Not all of the options need be 
physically connected to the LAN. Telephone calls are a valid 
substitute for letters, but may not be directly available 
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through the system. As long as their prices appear in the 
decision tool models, and they are listed as alternates on 
the appropriate function (Input, Output, Send, Analyze) 
menu, services like the telephone and the stand alone 
microcomputer will be included in information marketplace, 
and therefore subject to the management controls of the IRM 
architecture . 

Again, if the information decision tool is available 
through the LAN, its use can be recorded as measure of 
information awareness. If the LAN can access the separate 
communications and information subsystems to connect users, 
it can also access those subsystems to get current pricing 
and usage statistics for incorporation in the information 
decision tool models. 

The function menus insure that the user is reminded 
of the possible substitution alternatives at the time the 
choice is made. The decision tool insures that the best 
possible cost information is available to support the 
choice. Satisfying these requirements at the District LAN 
interface insures the choice is among all the options and 
all the information services available to the user's 
purpose, within the whole architecture, as opposed to only 
those choices available within a given information 
subsystem. 
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5. Standard User Interface 



Although not listed as a management control require- 
ment, the idea of a standard interface between the IRM 
architecture and the user is another physical way to 
strengthen the user's perception of the architecture as a 
unified system, as opposed to a collection of systems. It 
could easily be implemented in the proposed LAN environment 
by using a standardized interface in the programs designed 
to satisfy the control requirements. 

A hidden advantage to this approach is that it 
minimizes expense; once the interface is designed, the same 
specifications are used for each subsequent program. Only 
the information presented on the screen changes; the 
location of status information and instructions, the type of 
selection (e.g. by letter, from a menu), and all the other 
presentation characteristics are identical. It also shortens 
the user learning time. A user recognizes the format and 
can instantly transfer experience with the interface he or 
she gained using other programs. 

D. A VIRTUAL LAN 

A variety of networks are available to connect computers 
and communications devices, each with a variety of 
char ac te ri st ic s , and each calling itself a Local Area 
Network. Active or passive, broadband or baseband, central 
or distributed control, the list of options is almost 
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endless. Network technology is not fully developed yet, as 
the Support Plan recognized in deciding not to include it 
in the near-term budgets. The Local Area Network we have 
examined to support the integration and management control 
goals of the Coast Guard IRM Architecture is not a specific 
product. The phrase is intended to describe an ability to 
electronically cross -connect the users, computers and 
communications resources of a Coast Guard District Office in 
a productive way. This virtual LAN should provide reasonably 
guaranteed delivery of information between any pair of 
nodes, notification of non-delivery, and an auditable record 
of access and use of its services. 

This limited functionality is an adequate base from 
which to develop prototype systems or programs to satisfy 
the specified management control requirements, and is 
available at less technological risk than that a 'real' LAN 
represents. Shared logic word processors, such as WANG OIS- 
1 40 's provide electronic mail and hardware terminal 
identifiers; they have been connected to the record 
telecommunications system in the First and the Fifth Coast 
Guard Districts. The Eighth and the Seventeenth Coast Guard 
Districts are currently running Office Au tomation / Wor d 
Processing evaluations on Vax 11/780 computer based systems; 
these also support electronic mail, and have resource usage 
monitor programs available. The District minicomputers 
scheduled for FY 86 purchase and installation could provide 
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this virtual LAN function through their installed terminals 
and the appropriate programming. Any of these systems with 
a sufficiently large base of connected users could provide 
an adequate functional base on which to prototype a system 
or program intended to meet one or more of the management 
control requirements of the IRM architecture. 

E. SUMMARY 

We have presented the reasons that the Coast Guard 
District Office is the crucial level' within the IRM 
architecture at which to address the solution to management 
control requirements of that architecture. The power of a 
Local Area Network to physically reinforce the logical 
integration crucial to the IRM architecture and to the 
success of its management controls, was presented and 
examined for each of the management control requirements 
proposed in Chapter IV. Finally, a distinction was drawn 
between any specific technology or product and the virtual 
LAN functionality required to begin satisfying the 
requirements . 



64 



VI. CONCLUSION 



This thesis has attempted to present a positive 
description of the integrative power of management control, 
in the setting of a large information system. We have 
suggested that, properly developed, the management control 
structure can unify diverse information systems into a 
single architecture, and yet preserve a powerful, if subtle, 
ability to influence user choices. If developed early, the 
control structure can ease the necessary transitions of 
maturing information systems. 

The management control requirements proposed assume that 
the intention of the Office of C^ as program managers for 
the IRM architecture is to integrate the separate vertical 
information subsystems into a cohesive whole. The proposed 
LAN implementation of a system to satisfy the control 
requirements centers on accomplishing that purpose. Both the 
requirements and the LAN implementation should be evaluated 
with this underlying assumption of integrating the 
architecture in mind. Both would have to be modified to 
support a different concept of the architecture. 

This early delineation of a management control schema 
for the IRM architecture may have some practical 
significance for the U. S. Coast Guard. With major hardware 
and software procurements for the IRM architecture still 
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pending, the opportunity exists now to buy the features or 
capabilities that will be necessary to management control 
later on. More valuable than procurement opportunities may 
be the necessary lead time created for careful prototype 
development of the programs and systems that the management 
control structure will require. 

Although the Coast Guard IRM architecture was used as a 
focus for development of the suggested management control 
structure, the requirements and implementation presented 
could also be applied to other information systems. The 
organization served by the information system would need to 
have sufficiently centralized control of information 
services that one single, or several regional offices, could 
set transfer prices. The company culture would have to 
support the notion of user autonomy within limits, and 
decentralized decision responsibility. The transfer pricing 
basis of the control strategy assumes as well that 
information services costs are not allocated totally as 
overhead, but charged to users to a significant degree. 

Changing the information flows of an entire agency must 
change the structure, if not the nature, of the whole 
organization. Controlling the system which implements these 

changing information flows is a necessary step to insuring 

* 

that the development process will one of directed growth and 
not uncontrolled change. This examination of management 
control within information systems is meant to assist the 
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Coast Guard and other organizations in retaining 
organizational control of these technology-driven changes. 
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